One Map, Two Columns — And They Do Not Read The Same Way

Two columns, nine boxes, about thirty logos. Back end on one side — logic, data and APIs, running on a server. Front end on the other — what users see and click, running in the browser. As a way of ending the frontend-versus-backend confusion in four seconds, it works.

What it does not tell you is that the two columns follow completely different rules, and if you read them the same way you will make one of the two decisions much harder than it needs to be.

The front end column is a stack. The boxes sit on top of each other in a fixed order — the core technologies hold everything up, a library sits on those, a full framework replaces or extends the library, a CSS toolkit sits alongside. You climb it. You cannot start in the middle.

The back end column is a cascade. The boxes are not layers, they are consequences. Choose the language and three of the other boxes fill themselves in — which the card actually shows you, if you look closely at the framework box, where every logo is annotated with the language it belongs to.

The advice printed along the bottom of the card — pick ONE box per column and build something small this week — is good advice. This article is about what “one box” means on each side, because it is not the same amount of choosing.

Two columns, two rules

The map, box by box

The first three columns are the card’s own — its box titles, its one-line descriptions, its logos. The last column is ours.

The cascade, in one table

This is the part that saves a beginner two weeks. On the back end you are not making five choices. You are making one, and then reading off the consequences.

Notice what the table does not contain: a best answer. Every row ships real products, and the reason to pick one is almost never technical. It is what your first project needs, what the people around you already use, or what the jobs you are looking at ask for. We made that argument at length in Which Language Should I Learn First Is The Wrong Question — start from the thing you want to have built, and the language stops being a debate.

The one name that appears in both columns

Read the map again and you will find JavaScript twice. It is in the front end’s foundation box, next to HTML and CSS, where it is not optional. And it is in the back end’s language list, where an entire extra box — the runtimes — exists purely to explain how it gets there.

That is the single most useful fact on the card, and the layout hides it by putting the two mentions on opposite sides of a divider.

It means one language covers the compulsory half of the left column and a legitimate option on the right. Not because it is the best server language — it is not obviously better than the other four — but because it is the only one that removes a decision instead of adding one. For somebody starting this month, learning one language and being able to work on both sides of the map is worth more than a marginally better fit on one side.

The trap on the other side of that: one language is not one job. The browser half and the server half share syntax and share almost nothing else. Knowing JavaScript does not mean you know databases, or how a request actually arrives, or why the server fell over. The card is honest about this in its own quiet way — it gives the back end five boxes and the front end four, and only one name is in both.

Four honest caveats

Two of these boxes are not shopping lists. The API box holds GraphQL and REST, and the card itself labels REST an API style — it is a way of designing how two programs talk, not a thing you download. You will end up using one without ever having chosen it, because your framework already has an opinion. Treat that box as vocabulary, not as a decision due this week.

“Library” versus “framework” is a blurrier line than two boxes suggest. The card separates React and jQuery from Angular and Vue, which is a fair simplification and a useful one for a beginner. In practice React plus its usual companions does the job of a framework, and Vue can be used lightly or heavily. Do not spend an evening deciding which box something belongs in; spend it building the thing.

One logo on this map is mostly maintenance work. jQuery is on an enormous number of existing sites and you will meet it, so recognising it is genuinely useful. Starting a new project with it in 2026 is a different proposition, and the card’s own label — utility library — is doing polite work there.

The map stops before the hard part. There is no box for hosting, deployment, testing, security, or the thing that wakes you up when the site is down. That is not a flaw — it is a map of what goes where, not a map of shipping. But it does mean finishing every box on this card still leaves you a step short of a live site, which is why some people skip the whole map and use a builder instead. Whether that is the right trade depends entirely on what you want to own at the end, which we worked through in Describe The Site, Get A Live Page. Then What Do You Own?

What “build something small this week” should actually be

The card’s closing line is the best instruction on it, and most people ignore it because a map full of logos makes you want to study, not build. So make the small thing small enough that studying is not an option.

One page. Written by hand in the three core technologies, with no library and no toolkit. It should do exactly one thing that a static page cannot — take something a visitor types, send it somewhere, and show a different result. That is the whole front-end column’s bottom box and the entire point of the back-end column, in an afternoon.

Then add exactly one box, and notice what it saves you. Add the CSS toolkit and your page stops looking like 1998. Add a framework and your one page becomes three without copy-pasting. Adding boxes one at a time is how you learn what each box is for — which no map can teach you, because the map can only tell you what each box is called. The argument for that pace, applied to tools generally, is in Pick One Per Stage And Learn It Properly.

Questions people ask

Front end or back end first? Front end, because you can see it fail. A browser shows you your mistake immediately; a server mistake is invisible until you have learnt enough to look for it.

Do I need a framework at all? Not for anything small, and “large applications” is the card’s own condition on that box. A framework solves problems you have not got yet, and its cost is a set of conventions you must learn before you can do the simple thing.

Which database? The one genuinely free choice on the back end. For a first project any of the three on the card will do, and the differences only start mattering at a scale you do not have yet.

Is this map still current? The shape is. The logos move slowly here compared to the AI tool charts — a stack diagram from a few years ago would look much like this one. That stability is the reason learning any single box on it is a better use of a month than chasing whichever tool trended this week, which is the pattern we picked apart in Count The Plus Signs.

Pick one box per column

The card ends with the right instruction and this article has only added a footnote to it: on the left, “one box” means one layer, climbed in order from a bottom you cannot skip. On the right, “one box” means one language, after which three of the other boxes are already decided for you.

Read that way, a map of thirty logos turns into two decisions. Two decisions is something you can finish this week.

Learning a lot does not make anyone good. Doing a lot does.

If you want a deadline rather than another map, we run a free challenge — there is no barrier to entry, only a commitment fee that is refunded when you finish. It exists because a deadline builds the small thing, and a saved diagram never does.

Which box are you on right now, and what is the small thing you are building with it? Tell us in the comments under the original reel.

More on building a channel for a global audience at mmoyoutube.com.